{
    title:  'Routing',
    crumbs: [
        { "User's Guide": 'index.html' },
    ],
}
            <h1>Request Routing</h1>
            <p>Appweb includes a powerful request routing engine that processes client HTTP requests. The engine
            is configured with a set of routes and, when a request is received, it tests various routes and selects
            the best one to handle the request.  In the process, routes may redirect or rewrite the request 
            as required.</p>
            <img src="../images/routing.jpg" alt="routing" class="centered">
            <p>An Appweb configuration will typically have many routes. The configured routes 
            are tested in order by matching the route pattern against the request URI. 
            A route may require that further preconditions be met before it is suitable to process the
            request. If the required conditions are not met, the next route in the configuration will be tested. There 
            is always a catch-all route that will process the request if all prior routes fail to qualify.</p>
            <p>A route may modify the request during processing by changing the request URI or request data. The
            route may also run commands as a side-effect during processing.</p>
            <a id="configuration"></a>
            <h2>Route Configuration</h2>
            <p>Routes are defined in the appweb.conf configuration file or via an API and are processed at run-time when 
            client HTTP requests are received.</p>
            <p>The most fundamental directive is the Route Block directive which declares a new route block and defines the
                route matching pattern:</p>
<pre class="ui code segment">
&lt;Route /info/ &gt;
&lt;/Route&gt;
</pre>
            <p>This example defines a route pattern <em>/info/</em> that will match request URIs that begin with 
            <em>"/info/"</em>.  The route pattern is a regular expression pattern that is used to match against the 
            client request URI. If the route pattern matches the URI, the route is selected to process 
            the request.</p>
            <h3>Route Ordering</h3>
            <p>When multiple routes are defined in the configuration file, a client request will test each route 
            in the order in which they are declared in the configuration file. So ordering is very important. Routes
            with longer or more qualified route criteria should be defined first before more general routes.</p>
            <h3>Route Nesting</h3>
            <p>Routes can be nested where route blocks are placed inside other route blocks. The inner route
            will inherit the configuration that existed at the point the open route block directive appears in 
            the configuration file. </p>
            <p>When a route block is defined, it is not added to the list of routes until the closing &lt;/Route&gt; 
            directive is encountered.  This means that inner route blocks will be correctly defined before 
            their outer route block. For example:</p>
<pre class="ui code segment">
&lt;Route /info/ &gt;
    Documents /public-docs
    &lt;Route /info/private/ &gt;
        Documents /confidential-docs
        AuthType digest
        AuthName "Top-Secret"
        Require valid-user
    &lt;/Route&gt;
&lt;/Route&gt;
</pre>
            <p>This example assigns different physical directories for public and private information and secures
            the private information with digest authentication. The inner <em>/info/private</em> route will be 
            defined before the <em>/info</em> route and will be matched against the request URI before the
            <em>/info</em> route.</p>
            <h3>Default Route and Virtual Hosts</h3>
            <p>A hidden route is defined at the very top of the appweb.conf configuration file. This is the default
            route and all routes ultimately inherit from it. Route related directives outside a route block will 
            configure and modify the default route. </p>
            <p><em>VirtualHost</em> directives also define implicit route blocks. In this way, they inherit the route
            configuration that existed at the point in the configuration file where the VirtualHost is defined, but they
            can override this to create a unique route configuration for the virtual host.</p>
            <a id="directives"></a>
            <h2>Route Directives</h2>
            <p>Other route related configuration directives include:</p>
            <h3><a href="dir/route.html#addHandler">AddHandler</a> and 
                <a href="dir/route.html#setHandler">SetHandler</a></h3>
            <p>The <em>AddHandler</em> directive defines an Appweb handler for the route which will be used when the
            request extension matches one of the AddHandler extension arguments.  The <em>SetHandler</em> directive
            defines the Appweb handler to be used for the route regardless of the URI extension.</p>
            <h3><a href="dir/route.html#condition">Condition</a></h3>
            <p>The condition directive can define a condition test that must be true for the route to be selected. 
            Conditions have three test rules: <em>exists</em>, <em>directory</em> and <em>match</em>. The 
            <em>exists</em> rule evaluates if the condition filename argument exists in the file system. 
            The <em>directory</em> rule evaluates if the filename is a directory. The <em>match</em> rule
            tests the string argument against a regular expression pattern.
            A route may have any number of condition directives.</p>
            <h3><a href="dir/route.html#documentRoot">Documents</a></h3>
            <p>The directory containing documents can be defined via the <em>Documents</em> directive. If the client
            is requesting a physical document, the request URI is appended to the Documents directory to locate the 
            file to serve.</p>
            <h3><a href="dir/route.html#Header">Header</a></h3>
            <p>Header directives can define a required header and value that must be present for the route to be selected. 
            The header value 
            can also be negated by prefixing the name with "!". This negating also works for the Condition directive.
            A route may have any number of header directives.</p>
            <h3><a href="dir/route.html#logRoutes">LogRoutes</a></h3>
            <p>The <em>LogRoute</em> directive will display the route table to the error log.</p> 
            <h3><a href="dir/route.html#methods">Methods</a></h3>
            <p>A route can define the set of valid HTTP methods via the <em>Methods</em> directive. The standard 
            HTTP methods are:
            DELETE, GET, OPTIONS, POST, PUT and TRACE. The Methods directive can also take an argument of "ALL" or "*"
            to select all possible methods for the route.</p>
            <h3><a href="dir/route.html#prefix">Prefix</a></h3>
            <p>The prefix directive removes a prefix string from the request URI. This is often used to remove 
            an initial application name from the URI.</p>
            <h3><a href="dir/route.html#reset">Reset</a></h3>
            <p>If a route needs a completely clean configuration, the <em>Reset routes</em> directive can be used to
            remove all inherited configuration.</p>
            <h3>RouteName</h3>
            <p>Routes may be given a symbolic name that is used when displaying routes in the log file via
            the <em>LogRoutes</em> directive. The symbolic name is also used by some APIs to look up routes by name.</p>
            <h3><a href="dir/route.html#target">Target</a></h3>
            <p>The target directive specifies what action the route will take to respond to the request. The target
            directive has four rules: <em>close</em>, <em>redirect</em>, <em>run</em>, and <em>write</em>. 
            The <em>close</em> rule is used to immediately close a connection without responding to the client. This 
            can be used to mitigate denial of service attacks.  The <em>redirect</em> rule is used to redirect the 
            request to another URI. 
            The <em>run</em> rule is used to run the select handler to respond to the request.
            The <em>write</em> rule is used to respond to the client with literal text and is useful for 
            debug responses.</p>
            <h3><a href="dir/route.html#update">Update</a></h3>
            <p>The update directive modifies the request or environment. Updates have two rules: <em>param</em> and
            <em>cmd</em>. The <em>param</em> rule can be used to set the request <a href="#params">params</a> 
            to a specific value. 
            The <em>cmd</em> rule can be used to run external commands.</p>
            <a id="params"></a>
            <h4>Request Params</h4>
            <p>Request parameters are comprised of a set of request state information. This includes:</p>
            <ul>
                <li>Query field values</li>
                <li>Posted form fields</li>
                <li>Tokenized route pattern fields</li>
                <li>Fields explicitly set via the Update directive</li>
            </ul>
            <p>Different web frameworks expose request parameters in different ways. CGI provides access to
            request parameters via environment variables. In PHP, they are mapped to PHP server variables. In ESP 
            they are accessed via the <em>espGetParam</em> API, and in Ejscript, request parameters are exposed via
            the Request.params[] collection.</p>
            <a id="tokens"></a>
            <h2><a href="dir/route.html#tokens">Tokens</a></h2>
            <p>Target, Condition and Update directives can reference tokenized values that are expanded
            when evaluated at run-time. There are three classes of tokens:</p>
            <ul>  
                <li>System/Route variables &mdash; DOCUMENTS, LIBDIR, PRODUCT, OS, ROUTE_HOME, VERSION.</li>
                <li>Route URI tokens &mdash; these are the braced tokens in the route pattern.</li>
                <li>Request tokens &mdash; these are request state and property values.</li>
                <li>SSL tokens &mdash; these are the SSL connection state.</li>
            </ul>
            <h4>System and URI Tokens</h4>
            <p>System and URI tokens are of the form: <em>"${token}"</em> where "token" is the name of the variable or 
            URI token to substitute.</p>
            <h4>Request Tokens</h4>
            <p>Request tokens are of the form: <em>"${family:name=defaultValue}"</em> where the family 
            defines a set of values. 
            If the named tokens are not present, an optional default value "=defaultValue" will be used instead.
            These supported request token families are:</p>
            <ul>  
                <li>header &mdash; for request HTTP header values</li>
                <li>form &mdash; for request form values</li>
                <li>request &mdash; for request details</li>
                <li>ssl &mdash; for SSL state details</li>
            </ul>
            <h4>Request Family Tokens</h4>
            <p>The supported request key names are:</p>
            <ul>
                <li>clientAddress &mdash; the client IP address</li>
                <li>clientPort &mdash; the client port number</li>
                <li>error &mdash; any request or connection error message</li>
                <li>ext &mdash; the request extension</li>
                <li>extraPath &mdash; the request extra path after the script extension</li>
                <li>filename &mdash; the mapped request filename in physical storage</li>
                <li>language &mdash; the selected language for the request</li>
                <li>languageRoot &mdash; the langauge root directory</li>
                <li>host &mdash; the host name owning the route for the request</li>
                <li>method &mdash; the request HTTP method</li>
                <li>originalUri &mdash; the original, pre-decoded URI</li>
                <li>pathInfo &mdash; the path portion of the URI after the host and port information</li>
                <li>prefix &mdash; the route prefix</li>
                <li>query &mdash; the request query string</li>
                <li>reference &mdash; the request reference fragment. This is the URI portion after "#"</li>
                <li>scheme &mdash; the request protocol scheme. E.g. "http"</li>
                <li>scriptName &mdash; the request script or application name</li>
                <li>serverAddress &mdash; the server IP address</li>
                <li>serverPort &mdash; the server port number</li>
                <li>uri &mdash; the full request URI. May be modified by routes, handlers and filters</li>
            </ul>
            <h4>SSL Family Tokens</h4>
                <p>The supported ssl key names are listed below:</p>
                <table title="keys" class="ui table segment">
                    <thead>
                        <tr><th>Key</th><th>Example Value</th><th>Description</th></tr>
                    </thead>
                    <tbody>
                        <tr><td>state</td><td>CIPHER=TLS_DHE_RSA_WITH_AES_256_CBC_SHA, CIPHER_IANA=39, CLIENT_VERSION=3,...
                            </td><td>All the keys values below and the certificate values
                            in single KEY=VALUE, ... string</td></tr>
                        <tr><td>CIPHER</td><td>TLS_DHE_RSA_WITH_AES_256_CBC_SHA</td><td>Encryption cipher suite</td></tr>
                        <tr><td>CIPHER_IANA</td><td>0x39</td><td>IANA cipher code</td></tr>
                    </tbody>
                </table>
                <h4>SSL Certificate Key Tokens</h4>
                    <p>The keys below pertain to the client or server side certificate and are prefixed with either 
                        "CLIENT_" or "SERVER_".</p>
                <table title="certificates" class="ui table segment">
                    <thead>
                        <tr><th>Key</th><th>Example Value</th><th>Description</th></tr>
                    </thead>
                    <tbody>
                        <tr><td>VERSION</td><td>3</td><td>Certificate version</td></tr>
                        <tr><td>SERIAL</td><td>00:89:89:4C:64:02:32:E9:8A</td><td>Certificate serial number</td></tr>
                        <tr><td>S_C</td><td>US</td><td>Subject country</td></tr>
                        <tr><td>S_ST</td><td>Washington</td><td>Subject state</td></tr>
                        <tr><td>S_L</td><td>Seattle</td><td>Subject locality</td></tr>
                        <tr><td>S_O</td><td>Example Inc.</td><td>Subject organization</td></tr>
                        <tr><td>S_OU</td><td>Development</td><td>Subject organizational unit</td></tr>
                        <tr><td>S_CN</td><td>localhost</td><td>Subject common name</td></tr>
                        <tr><td>S_EMAIL</td><td>dev@example.com</td><td>Subject email address</td></tr>
                        <tr><td>I_C</td><td>US</td><td>Issuer country</td></tr>
                        <tr><td>I_ST</td><td>Washington</td><td>Issuer state</td></tr>
                        <tr><td>I_L</td><td>Seattle</td><td>Issuer locality</td></tr>
                        <tr><td>I_O</td><td>Example Inc.</td><td>Issuer organization</td></tr>
                        <tr><td>I_OU</td><td>Development</td><td>Issuer organizational unit</td></tr>
                        <tr><td>I_CN</td><td>localhost</td><td>Issuer common name</td></tr>
                        <tr><td>I_EMAIL</td><td>dev@example.com</td><td>Issuer email</td></tr>
                        <tr><td>START</td><td>2012-06-25 12:51:01</td><td>Certificate valid 'not before' date</td></tr>
                        <tr><td>END</td><td>2014-06-25 12:51:01</td><td>Certificate valid 'not after' date</td></tr>
                        <tr><td>CIPHER</td><td>RSA_SHA1</td><td>Certificate encoding cipher</td></tr>
                    </tbody>
                </table>
            <h4>Example</h4>
            <p>For example, to select the client's browser string passed in the HTTP headers:</p>
<pre class="ui code segment">Target run ${header:User-Agent}</pre>
            <p>To select a form field value, consider if the URI <em>/info/Mary</em> matched the pattern:
            <em>^/info/{name}</em>. Then the <em>${name}</em> token could be used in a Target run rule as such:</p>
<pre class="ui code segment">run ${name}.html</pre>
            <a id="processing"></a>
            <h2>Route Processing</h2>
            <p>To process a request, The Appweb route engine examines each of the configured routes to determine the 
            best matching route for a request.  It does this by considering each route in the order it is defined in
            the configuration file. Each route is tested over a sequence of steps. 
            Not all steps are required. However, the selected route will always perform pattern match, param definition and 
            target execution.  If a route fails to match at a step, the route is discarded and the next configured route 
            is considered.</p>
            <img src="../images/routeSteps.jpg" alt="steps"/>
            <h3>Routing Steps</h3>
            <ol>
                <li><a href="#step-pattern">Pattern Matching</a> &mdash; Test if the request URI matches route pattern.</li>
                <li><a href="#step-method">Optional Method Matching</a> &mdash; Test if the request method is valid.</li>
                <li>Optional <a href="#step-header">Header Matching</a> &mdash; Test if the request has the require headers.</li>
                <li>Optional <a href="#step-form">Form Field Matching</a> &mdash; Test if form data has required values.</li>
                <li>Optional <a href="#step-condition">Condition Matching</a> &mdash; Test if the required conditions are true.</li>
                <li>Optional <a href="#step-update">Updates</a> &mdash; Modify the request with specified updates.</li>
                <li><a href="#step-param">Param Definition</a> &mdash; Define tokens as request 
                    <a href="#params">params</a>.</li>
                <li><a href="#step-target">Target Execution</a> &mdash; Select the Appweb handler and determine the target resource.</li>
            </ol>
            <h3>Route Timing</h3>
            <p>Appweb will initiate request routing at a different time depending on whether the request has form data. 
            If a request has form data, it is worthwhile to delay routing until after the form data
            has been read from the client. This enables the routing directives to take action based on the received form
            data. If a request has no form data, it is routed immediately after the HTTP headers have been read and 
            parsed.</p>
            <p>A request with form data has a <em>Content-Type</em> header of
            <em>application/x-www-form-urlencoded</em>. Requests with a <em>Content-Type</em> set to 
            <em>multipart/form-data</em> which indicates form based file upload, will also delay routing until the uploaded
            file has been fully received.</p>
            <a id="step-pattern"></a>
            <h3>Pattern Matching</h3>
            <p>A route pattern is a specially prepared regular expression that can be quickly matched against the 
            request URI. The route pattern may match the entire request URI, just a subset at the start of the URI
            or any portion in between. Regular expressions are ideal for route patterns as they can express a wide 
            variety of URI formats and can also extract sub-expressions for later evaluation.</p>
            <h4>URI Tokens</h4>
            <p>Often the request URI will not only provide a path to a resource, but it will contain tokens of 
            information that must be isolated and extracted from the URI. Appweb route patterns provide an easy and
            efficient means to extract such tokens and define them as request <a href="#params">params</a>.
            To do this, Appweb route patterns extend the standard regular expression syntax via embedded tokens.</p>
            
            <p>A token is a 
            portion of the URI that is enclosed in braces "{token}". The token name is a symbolic name that will be used
            later to define a request parameter. In the request URI, any sequence of characters except 
            "/" are acceptable in the token name. For example the route pattern:</p>
<pre class="ui code segment">
&lt;Route ^/{controller}/{action}$&gt;
</pre>
will match the URI:
<pre class="ui code segment">
/user/login
</pre>
            <p>After pattern matching, the request param <em>controller</em> will be set to "user" and 
            <em>action</em> will be set to "login".</p>
            <p>Token values can be accessed in condition, update and target directives via the <em>${token}</em> syntax.</p>
            <p>To enable the extension token syntax, the standard regular expression syntax for repeat sub-expressions 
                that uses braces: {m,n} needs to be back-quoted. i.e. \{m,n}.</p>
            <h4>Sub-Expressions</h4>
            <p>In addition to route tokens, standard regular expression sub-patterns can be defined by wrapping a 
            sub-expression in parentheses. For example:</p>
<pre class="ui code segment">
&lt;Route /(user|admin)/{cmd}&gt;
</pre>
            <p>This will allow URIs that begin with either <em>/user</em> or <em>/admin</em>. Sub-expression and token
            values are made available to Conditions, Updates and Targets by using <em>$N</em> in the directive details. 
            The first sub-expression or token is assigned to <em>$1</em>, the second to <em>$2</em> and so on. 
            If a request with the URI <em>/user/login</em> was received, the route above would set <em>$1</em> to 
            "user" and <em>$2</em> to "login".</p>
            <h4>Conditional Sub-Expressions</h4>
            <p>Conditional sub-expressions can be defined by wrapping in "(~" and "~)". This means the wrapped
            sub-expression is valid but not required. For example:</p>
<pre class="ui code segment">
&lt;Route /{controller}(~/{action}~) &gt;
</pre>
will match any of the URIs:
<pre class="ui code segment">
/user
/user/
/user/login
</pre>
            <h4>Anchoring Route Patterns</h4>
            <p>It is wise to anchor route patterns to the start of the URI. This is done by using the <em>"^"</em> character
            at the start of the URI. If the pattern describes the full request URI, the pattern can anchor to the end
            of the URI by appending <em>"$"</em>. For example:</p>
<pre class="ui code segment">
^/{controller}(~/{action}~)$
</pre>
            <a id="step-method"></a>
            <h3>Method Matching</h3>
            <p>Method matching is an optional step. Routes can be configured to only match certain HTTP methods. 
            Method matching tests the supported route methods against the actual request HTTP method. 
            By default a route supports all methods</p>
            <a id="step-header"></a>
            <h3>Header Matching</h3>
            <p>Header matching is an optional step. Routes can be configured to require that the request has HTTP
            headers with or without defined values. For example: a route may wish to only be relevant for a 
            particular browser:</p>
<pre class="ui code segment">
&lt;Route /info/ &gt;
    Header User-Agent /Chrome/
&lt;/Route&gt;
</pre>
            <a id="step-form"></a>
            <h3>Form Value Matching</h3>
            <p>Form value matching is an optional step. Routes can be configured to require that the request has 
            form data with or without defined values. Form data is sourced from the request URI query string and from
            form body (POST) data. Form data must have a Content-Type of "application/x-www-form-urlencoded" &mdash;
            normal HTML forms are encoded this way.</p>
<pre class="ui code segment">
&lt;Route ^/info/ &gt;
    Query name /(Mary)|(John)/
&lt;/Route&gt;
</pre>
            <p>This route will match the URIs: </p>
<pre class="ui code segment">
/info/file.html?name=Mary
/info/file.html?name=John
</pre>
            <a id="step-condition"></a>
            <h3>Condition Matching</h3>
            <p>Condition matching is an optional step where extra conditions can be tested before the route is selected.
            Conditions can test if a file exists or not and whether a file is a directory or not. Condition rules
            can also test any request parameter against a regular expression.</p>
            <a id="step-update"></a>
            <h3>Request Update</h3>
            <p>Request update matching is an optional step where the request <a href="#params">params</a> 
            can be modified.</p>
            <a id="step-param"></a>
            <h3>Param Definition</h3>
            <p>After a route fully qualifies, request <a href="#params">params</a>
            are created for route pattern tokens. This provides an
            easy mechanism for extracting useful information from the request URI and passing it to the web page or
            controller for processing.</p>
            <a id="step-target"></a>
            <h3>Target Execution</h3>
            <p>Route targets have responsibility to generate the actual response to the client.
            But, before the target can be executed, the appropriate request handler must be selected.
            If a route has an explicit handler defined via <em>SetHandler</em> then that handler will be used.
            If a set of handlers have been defined via <em>AddHandler</em> directives, then the handler defined with 
            the corresponding URI extension will be selected.</p>
            The target has four possible rules: <em>close</em>, <em>redirect</em>, <em>run</em> and
            <em>write</em>.  Of these, all except for the <em>close</em> rule take parameters that are 
            expanded using the matching sub-expressions and/or route tokens derived when matching the route pattern.
            <p>Target rule parameters can use <em>"${token}"</em> to be replaced with the value of the token.
            Target rule parameters can also use <em>"$N"</em> to be replaced with the Nth matching sub-expression, 
            <em>"$&amp;"</em> to be replaced with the entire
            matched pattern, <em>"$`"</em> to be replaced with the portion that precedes the matched pattern and 
            <em>"$'"</em> to be replaced with the portion that follows the matched pattern. 
            <p>For example:</p>
<pre class="ui code segment">
Target write 200 "Running controller ${controller} action ${action}\n\n"
</pre>
            <p>This will write the message back to the client with a HTML status code of 200 .</p>
            <p>Note: to be more secure, the <em>write</em> rule will escape embedded HTML sequences. If you need to emit
            HTML, use the <em>-r</em> switch for raw write output.</p>
            <h3>Prefix Removal</h3>
            <p>If Appweb is running several applications, it will need to be able to route and distinguish 
            requests for each application. There are two primary ways to achieve this: run each application
            in a separate virtual host or uniquely prefix the URIs for each application. If using the latter approach,
            routes can be defined for each application that specify the URI prefix for each application. However, it is
            often convenient to have the application prefix removed from the URI once the route is selected. The Prefix
            directive defines a URI prefix that will be stripped from the start of the request URI once the route
            is selected. If the route defines a header, form or condition that is not satisfied, the prefix is restored
            to let other routes see the full URI.</p>
            <a id="examples"></a>
            <h2>Route Examples</h2>
            <h3>Redirecting Old URIs</h3>
            <p>To redirect requests for old documents to newer versions:</p>
<pre class="ui code segment">
&lt;Route ^/public/oldFile.html$&gt;
    Target redirect 302 /public/newFile.html
&lt;/Route&gt;
</pre>
            <h3>Authenticating Private Content</h3>
            <p>To secure private content :</p>
<pre class="ui code segment">
&lt;Route /private/ &gt;
    Documents /private-docs
    AuthType digest
    AuthName "Top-Secret"
    Require valid-user
&lt;/Route&gt;
</pre>
            <h3>Serving Compressed Content</h3>
            <p>This example enables the serving of compressed content where an equivalent compressed document exists. i.e.
               A request for <em>/manual/overview.html</em> may return <em>/manual/overview.html.gz</em> if it exists. If
               there is no compressed content, the uncompressed version is returned.</p>
<pre class="ui code segment">
&lt;Route ^/manual/ &gt;
    Compress gzip
&lt;/Route&gt;
</pre>
            <h3>Multi-Language Content</h3>
            <p>This example stores English content under the <em>"english-docs"</em> directory and French under the 
            <em>"french-docs"</em> directory. The client's browser should include an <em>Accept-Language</em> 
            header which stipulates which language is preferred.
            If the accept header is missing or the requested language is not English or French, then the DefaultLanguage
            directive indicates that english content should be returned.</p>
<pre class="ui code segment">
&lt;Route / &gt;
    DefaultLanguage en
    AddLanguageDir en /path/to/english-docs
    AddLanguageDir fr /path/to/french-docs
&lt;/Route&gt;
</pre>
            <h3>Multi-Language by Suffix</h3>
            <p>This example stores content for all languages together and includes a language suffix to the request document
            filename. If the client requested a French version of <em>index.html</em>, then the document 
            <em>index.fr.html</em> would be served.</p>
<pre class="ui code segment">
&lt;Route / &gt;
    DefaultLanguage en
    AddLanguageSuffix en en before
    AddLanguageSuffix fr fr
&lt;/Route&gt;
</pre>
            <h3>Application Isolation</h3>
            <p>To group routes for an application, enclose in a Route block and use a Prefix directive to remove the
                application prefix.</p>
<pre class="ui code segment">
&lt;Route /manage/ &gt;
    Prefix /manage
    Documents manage-app
    SetHandler espHandler
    &lt;Route /manage/{controller}/{action}&gt;
        Target run ${controller}-${action}
    &lt;/Route&gt;
&lt;/Route&gt;
</pre>
            <h3>Denial of Service Protection</h3>
            <p>To immediately close a connection without responding use the <em>Target close</em> directive.
<pre class="ui code segment">
&lt;Route /hacked-url/ &gt;
    target close
&lt;/Route&gt;
</pre>
            <h3>Missing File</h3>
            <p>To match a missing document without redirection:</p>
<pre class="ui code segment">
&lt;Route / &gt;
    Condition ! exists ${request:filename}
    Target run /missing.html
&lt;/Route&gt;
</pre>
